技術調査の結果を表にまとめる際のコツについて考えてみた

#オペレーション

nayu.t.s

2023.05.01

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

データアナリティクス事業本部の鈴木です。

以前、『私流・データ分析基盤の技術調査のコツを整理してみた』にて、表での整理をご紹介しましたが、具体的にどういう手順や考え方で進めるとよいか、自分の考えをもう少し掘り下げたかったのでブログ記事にまとめてみました。

以下の流れでご紹介できればと思います。

私がよく使う表のテンプレート
整理観点を表す表題の決め方
作業段階に相応な粒度の表の作成
表の出来栄えの確認方法

また、表を作成するために便利なツールについても記載します。

私の経験をベースとした内容なので、あくまで1例としてではありますが、参考になれば思います。

前提

紹介する表の用途について

技術調査の結果を表形式で整理し、後から見直したり誰かに説明したりする用途を想定して記載します。特に自社のチームメンバー向けのものを想定しています。

表を書くときのルール

表を書くときのルールとして、この記事では以下の2点を前提としています。

表の右側に行くほど補足になるべき
分類を表すカラムについては、抜けがあるといわれないような書き方にするべき

ここで記載した構成については、以下の記事も参考にしてください。

1. 私がよく使う表のテンプレート

まず最初に、私が特に社内向けとしてよく使っている表のテンプレートを紹介し、その意図を説明します。

テンプレートの紹介

特に社内向けに、私は以下のような形の表をよく使っています。

表のテンプレート

パーツと目的

上記のテンプレートは、大きく以下のパーツと目的でできています。

No	パーツ	目的
1	No（項番）	みんなで案について討議する時に呼びやすくする。（No.1とか案1とか）
2	おすすめか	どれが表の作成者のおすすめの案か、すぐに分かるようにする。
3	観点	案を検討した際の観点を表す。このカラム内の分類は足して100%になる必要がある。ならない場合は抜け漏れが発生している。
4	案	提案する案を記載する。
5	メリット/デメリット	案を決定できるよう、それぞれのメリット・デメリットを記載する。
6	備考	ここまでに書ききれない内容があれば書く。

テンプレートの特に重要な点の補足

上の表の「目的」にパーツに込めた設計意図は記載しましたが、特に重要な点を掘り下げてご紹介します。

観点はカラム内で足して100%になるように心がける

調査対象に抜け漏れがないように分類は足して100%になるように心がける必要があります。

例えば、記事執筆時点での気象庁の予報区分の一覧表のページには、全般季節予報で用いる予報区分に「北日本」・「東日本」・「西日本」・「沖縄・奄美」があると記載されています。

そのため、「全般季節予報で用いる予報区分」というカラムを表に用意する場合、必ずこの5つの値がある必要があります。もし足りない場合は検討漏れです。

とはいえ全部のパターンを載せていると表が大きくなりすぎたり、調査が細かくなったりすることはあります。そういうときは項目をまとめてしまうのがよいと考えています。これについては後述します。

重要な観点を粗く記載するのはダメですが、そうでない内容については「それ以外」ととりあえず書いてあること自体が重要だったりします。例えば何かの機能を考える時に「○○できること」よりも「○○できないこと」の方が大きな価値を持ったりすることがあります。個人的には、抜け漏れが嫌がられる大きな理由の一つは、まとめる際に「○○ない」の情報が落ちてしまうことを防ぎたいというものがあると考えていて、極力足して100%になるように整理するとよいと思っています。

2. 整理観点を表す表題の決め方

次に観点部分を埋めるための考え方についてご紹介します。

整理観点を表す表題について

先に紹介したテンプレートの整理観点を表す表題は、技術調査における調査観点に対応します。技術調査の結果を表でまとめる際には、表題は対等なものが多いので、順番で迷ってしまうことがよくあります。

観点パーツ

個人的には、この順序は、解決したい課題で大事な順番に並べるとよいと考えています。理由は以下の2つです。

「表の右側に行くほど補足になるべき」ルールがあるため
表を使って説明する際には当然大事なことから説明するので、話す順番に整理しておいた方が説明もしやすくなるため

「大事な順番」は整理する人の考え方によりますが、決めやすいよう、重要だと思っている方法についてご紹介します。

観点の順番を決めるために重要な方法

調査目的を確認する

調査観点の大事さは、調査目的によります。なんのための調査なのかをよく確認しましょう。

特に以下のような軸で目的を分析すると観点としてなにを使うか考えやすいのでご紹介します。

どんな要件のための調査なのか
どんな課題を解決したいのか
誰向けの資料なのか
どんな前提条件があるのか
どんな手段が妥当そうなのか
どれくらいの時間で実現できないといけないのか

よくある技術的な観点から選ぶ

よくある重要な観点から選んでみるのも良いです。例えば観点の例を以下に挙げてみます。

料金（高いか、安いか）
環境構築（自分達で用意する必要がどの程度あるか）
サービスの形態（SaaS・PaaS・IaaSなど）
実行環境のタイプ（サーバーレスやマネージドなど）
トリガー（プッシュかプルか）
柔軟性（できることがどの程度決まっているか）
インターフェース（開発がGUIかCUIかなど）

表の作成が上手い人は、この「よくある重要な観点」を挙げられる数が多いと思います。この数の増やし方はどうしても個人の経験や力量によりますが、例えば書籍やブログ記事などで網羅的に観点を挙げてくれているものがあれば意識的にチェックする習慣を持つと蓄えやすいです。

しっくりくる説明の順番に並べる

表は作ったら人に説明すると思いますが、朧げに説明内容を想像できるときは、それに合わせて表題を決めると頭が整理されて、表題順もすっきり決まることがあります。

結論ありきで表の作成や技術調査をするのは良くありませんが、ある程度仮説とストーリー性を持ちつつ、表を作ることで自分の中で漏れていた視点を発見して網羅的な調査ができるのであれば、とてもよいと思います。

ただしこれによって抜け漏れが発生したり、調査結果が恣意的にならないようには注意しましょう。

3. 作業段階に相応な粒度の表の作成

調査の報告は作業段階に応じて何度かに分けるとよいように思っています。「観点はカラム内で足して100%になるように心がける」で観点カラムの値の粒度はあまり細かくしなくてもよく、場合によってはまとめてしまっていいことを記載しました。この粒度は調査の作業段階やレビュアーの知りたいことにうまく合わせると時間を節約して、後工程の作業を先に進めることもできます。そのためのポイントについてご紹介します。

技術調査の作業段階について

以前、技術調査のレビューは以下のような時間配分で設定すると上手く行きやすいということをご紹介しました。

レビュー準備の時間配分

ここまでで表のテンプレートと案の分類のための観点の洗い出し方について記載してきましたが、どの時点で完璧な表にするかはまだ書いていませんでした。

いつまでにどんな完成度の表を作るのかについては、作業段階に合わせて育てていくのが良いと考えているのでご紹介します。

表の育て方の例

分かりやすい表を作成するのは難易度が高い作業です。完璧なものを作ろうと思うと当然時間もかかります。もし一発で完璧なものを作ろうとすると、万が一、レビュアーが欲しかった表と作った表が違っていた時に大きな手戻りになってしまいます。

それを避けるために、作業段階に合った粒度の表を作っていくのがおすすめなので、その例を記載します。

なお、例として以下のような課題に対する解決案の表を作成するとします。

Amazon S3上にある形式が分からないログデータをパースして、必要な情報をテーブルデータにする方法を調べたい。この仕組みは1から開発する。ログは別にデータを貯めておく場所があり、バッチでこのシステムに連携される。

進捗確認時

この作業段階では、想定している前提が求められている前提と一致しているか確認します。この段階で知りたいのは、左の方の表題の選定が、説明を受けたい相手やレビューをしてくれる相手の想定と合っているか確認することです。

例として、先に挙げたよくある観点のうち、「実行環境のタイプ」を選んでみました。

Amazon S3上にあるログデータをパースするということだったので、サーバーの管理をする必要がなく、ある程度のパワーがある方法がよさそうです。一方で、自分でサーバーを立てて、場合によってはログの量を見積もってクラスターを構築しないといけない方法はかなり大変かもしれません。

例えば、まずはAmazon Athenaを使った方法が思い付きます。AthenaにはRegex SerDeがあるので、ログフォーマットが分かっているのであれば、要件は満たせそうです。

万が一AthenaのSerDeで扱いきれないフォーマットのデータだったような場合は、Amazon GlueやAmazon Athena for Apache SparkのようにSparkを使ってより細かな加工とパワーを両立する仕組みが候補になるかもしれません。

以上を踏まえると、以下くらいの表を作成しておくと、方針合わせができそうです。

進捗確認時

この時点で「自分達でサーバー管理はしたくないからNo.1のAthenaの調査をメインにして、No.2のGlueは念の為くらいに調べておこうか。」という判断になるかもしれません。そうすると100%完成した表をいきなり目指すよりもNo.3の選択肢の調査時間が大幅に削られるので、その分の時間を別のことに使えます。

中間レビュー時

進捗確認時のコメントを受けたとして、もう少し記述を追加してみました。

2つ目の表題は柔軟性としました。（網羅性という意味ではちょっと表にはまとめづらかったですが）

中間レビュー時

Athenaの案はもう少し考えてみようとなったので、No.1とNo.2に分割してみました。

No.4は仮装マシンの案のイメージをレビュアーが持ちやすいように、Embulkを使った例を記載してみました。これは私が以前Embulkを使った機能の開発経験があり、例として説明しやすいためです。

ここまで作っておけば、「No.1の具体的な構成を最終レビューまでに考えてみよう」という話になるかもしれません。つまり仮装マシンの案の調査の分の時間を、実際の構成の検証に回すことができ、一発で完成形の表を準備するよりも数日分早く設計を進めることが可能になりました。

また、なにかの要件で、やっぱり仮装マシンの案じゃないとだめだったとなった場合、表を見れば、「ノウハウがあったNo.4までは挙げて相談したけど、それ以外の方法の深掘りはまだしていなかったから、そこを続きとしてやろう。」とすぐに分かるので、素早く着手することができます。

4. 表の出来栄えの確認方法

各フェーズにおいて、説明の準備として十分かどうかはどう評価すればよいでしょうか。

一つの方法としては、表を使って実際に説明ができるか試してみることをおすすめします。

もし、すらすらと自分の考えが説明できるのであればその表でOKとして良いと思います。一方で説明に詰まってしまうなら、詰まった箇所を整理し直すとよいかもしれません。

例えば上記の表を使った場合、以下のような説明ができます。

技術調査を行いました。私としては案1がよいと考えています。これはAWSのサーバーレスなサービスを使う案です。Athena SQLの仕様内で処理を記述できる必要がありますが、AthenaはSQLが書ければ誰でも利用でき、スキャン量に対して課金になり、安く済ませやすい上にサーバーの管理が不要で大きなメリットがあります。Athena SQLで処理を表現できない場合がある点とサーバー台数を制御できない点はデメリットです。